package com.coderman.infosys.auth.domain.bo.authority;


import lombok.Data;
import lombok.ToString;

import java.util.List;
import java.util.Map;

/**
* @Description:系统菜单权限类
* @Author:shenshuai
* @CreateTime:2022-01-02 15:27:38
* @version v1.0
*/
@Data
@ToString
public class SystemAuthorityBO  extends  AuthorityBO{


   public SystemAuthorityBO(){}

   public SystemAuthorityBO(String authCode){
      this.authCode = authCode;
   }

   /** 权限编码标示 **/
   private String authCode;

   /** 业务数据系统标示 **/
   private String systemCode;

   /** 菜单 **/
   private String moduleCode;

   /** 按钮 **/
   private String menuCode;


   /**
    *
    * 2022-01-09：
    * 上面的systemCode,moduleCode,menuCode是平铺的系统权限模型
    * 所以在数据结构上会显得模糊，比如可能是样的数据组织方式
    * s1,mo1,me1
    * s1,mo2
    * s2
    * s3,mo2,me1
    * 那么这样的话我们在与业务方对接的时候可能需要在聚合根的地方进行一次工厂化的处理，
    * 当然更好的一种方式是我们可以在底层模型中去存一个Map,然后做json化
    * 这么做的一个很好的理由就是这个关系对象足够稳定,
    * 这样的第一层key:是系统key,由于SystemAuthorityBO本身就是系统维度的，在AuthorityBO这个聚合根中
    * 引用的就是多个系统维度的，所以可以很容易的进行聚合,当然这种聚合只是模型上模型标示的一个快照，我们不能拿menuCode去绕过SystemBO聚合做一些访问，当然尽量别这么做
    *
    *
    * 由于底层数据模型可能已经这样了，因此这个属性就先加上吧，现在我们用常规的方案走AuthorityFactory构建DTO层面的权限传输模型
    *
    * 2022-01-10：
    * 这里同样可能因为受到了数据结构的影响，导致树形结构建模出现问题，
    * 如果从聚合的角度来讲下面的属性可能更适合使用List<SystemBO> systemBOList来表达
    * 但是在构建的时候可能会比较麻烦，因为聚合引用深度的问题，所以这里应该还缺失一些逻辑体现
    *
    *  systemBOList 与  systemAuthCodeMap的相互转换
    *
    *  2022-01-10 V2：
    *   值对象？？？
    *
    */
   public Map<String, Map<String, List<String>>> systemAuthCodeMap;


   public static SystemAuthorityBO ofIdentifer(String authCode){
      return new SystemAuthorityBO(authCode);
   }

   public SystemAuthorityBO build(String systemCode,String moduleCode,String menuCode){
      this.systemCode = systemCode;
      this.moduleCode = moduleCode;
      this.menuCode = menuCode;
      return this;
   }



}